• Inflexible standard classification of test levels - As mentioned before, many organisations use a standard classification of test levels. Adapting this may require excessive energy or even be unfeasible. In these cases, the test manager should mould the tests to be executed into the existing test levels.
• Order of test level execution - A classification into test levels does not necessarily mean the order of execution of tests. A planned performance test in a production acceptance test (PAT) can sometimes be executed very early on, possibly even before the users acceptance test or just after or even in parallel to the system test. In other words, even if the PAT is the last in a list of test levels, this does not mean it has to be executed last. This is determined when creating the planning and also depends on the risks to be covered.

Determining the strategy is more than just the mechanical allocation of test thoroughness bullets based on the risk classes. Other aspects involved are:

• Adequately classifying the test levels to be used
• Performing evaluations/reviews, so that defects can be detected at an early stage when they can be reworked at relatively low cost
• Refined delimitation of total testing and the individual test levels, so that the scope of each test level becomes clear
• Non-testers have difficulty interpreting such tables. You should therefore add an explanation that can be understood by everyone (what is tested, at what depth/coverage ratio, how is overlap prevented, etc).

• In particular for functionality: a thoroughness of ••• for a test seems to suggest that, in this test level, the entire (sub)system must be tested at the greatest possible depth. This is not the case! The number of bullets indicates that heavier, similar or rather lighter testing than average is required. As such, it falls to the test manager of the test level in question to elaborate this further in the detailed test strategy.
• When determining the strategy, the test manager must take the weighing of cost, time and required competencies into account as much as possible. If he knows that there is a very limited budget, or that the available people do not have experience with testing, he must refrain from proposing 'impossible’ strategies such as very costly tests or very thorough test design techniques (to avoid many feedback cycles).
• The starting point is that a test must be executed as early as possible in the system development process. This reduces the rework costs. Depending on the desired coverage of a risk, one might think of an early usability test in the development environment. However, not every characteristic can be tested at an early stage. E.g. testing suitability requires the presence of a (nearly) complete system.